home *** CD-ROM | disk | FTP | other *** search
/ Personal Paint v7.1 / Cloanto Personal Paint v7.1.iso / utilities / developer_docs / screens / screens.doc next >
Text File  |  1996-11-01  |  7KB  |  120 lines
  1.  
  2.  Notes on the Screens Used by Cloanto Graphics Software
  3.  
  4.  November 2, 1996 - All Versions 
  5.  For more information please send E-mail to <support@cloanto.com>, 
  6.  or check <http://www.cloanto.com/amiga/>. 
  7.  
  8.  
  9.  Introduction
  10.  
  11.  Except where indicated otherwise, these notes apply to the screens opened
  12.  by Personal Paint, Personal Fonts Maker 2 and ColorType screens. The
  13.  information contained herein has been written for developers of software
  14.  which locates, grabs, selects, switches to front/back, promotes or performs
  15.  other functions on screens.
  16.  
  17.  
  18.  Screen Title Information
  19.  
  20.  The Cloanto packages to which these notes apply do not have a Screen title
  21.  (the corresponding pointer is NULL). This was not possible, as under many
  22.  conditions it could not be afforded to have a standard screen bar with
  23.  system-rendered text indicating the name of the program and potentially
  24.  overwriting other data. A consequence of this is that software that scans
  25.  the list of Amiga screens needs to take additional steps if it wants to
  26.  locate information such as the screen title, rather than presenting an
  27.  empty field to the user.
  28.  
  29.  All Cloanto graphics programs can easily be recognized. If the scan of the
  30.  list of windows in a screen having a NULL title determines that it contains
  31.  a window as wide as the screen, and one pixel tall, then it is very likely
  32.  a Cloanto screen of the type described here. The UserData field of that
  33.  window points to the title. To make the process reliable even in the event
  34.  that another application uses a similar format, it is best to check that
  35.  UserData is non-NULL, and that the string ending with '\0' has a
  36.  "reasonable" length (<255) and does not contain any unprintable characters
  37.  (having codes smaller than 32, or ranging between 127 and 159).
  38.  
  39.  
  40.  Screen Promotion
  41.  
  42.  While Cloanto packages are in general compatible with screen "promoters"
  43.  (utilities that intercept a request to open a given screen, and open
  44.  another type and/or size of screen instead), it is never safe to promote
  45.  from double-buffering to non-double-buffering modes (in the case of
  46.  Personal Paint playing an animation), or from non-RTG to RTG modes, or vice
  47.  versa. In case of difficulties, the documentation of Personal Paint advises
  48.  the user to disable the screen promoting software. Ideally, any screen
  49.  promotion software should include similar notices, or make similar
  50.  considerations.
  51.  
  52.  
  53.  Transition Screen
  54.  
  55.  When Cloanto programs change screen mode (for example, from PAL to NTSC),
  56.  they try to prevent that the System Workbench screen opens (if it was
  57.  closed) or appears to the front. This would be possible by opening the new
  58.  screen first, and then closing the old screen, but doing so has the
  59.  disadvantage of requiring, for a brief moment, possibly almost twice as
  60.  much RAM, which may not be available. Therefore, Cloanto programs such as
  61.  Personal Paint first open a one-bitplane transition screen, then close the
  62.  first screen, open the new screen and finally close the transition screen.
  63.  The transition screen also contains a window, in order to always satisfy
  64.  Console I/O requirements in case there is no other window in the system.
  65.  During the transition phase, both the transition screen and the mouse
  66.  pointer sprite are colored with the current color 0, to make them as
  67.  "discrete" as possible. The size of the transition screen is as small as is
  68.  allowed by the Display Database information, and in any case not smaller
  69.  than 320╫200 (it used to be smaller in older versions of Personal Paint,
  70.  but some graphic systems which contained incorrect Display Database entries
  71.  would crash). The reason why the screen has only one bitplane and is as
  72.  small as possible is that it must occupy as little RAM as possible.
  73.  
  74.  We encourage developers of Amiga compatible graphics subsystems to test
  75.  their system with Personal Paint changing screen modes between various
  76.  Amiga modes and various other screen modes. We have learned that the quick
  77.  and repeated actions of opening and closing various screens and windows is
  78.  a good way to test such a graphic system.
  79.  
  80.  
  81.  Virtual Blitter
  82.  
  83.  Cloanto packages always used the Amiga (Agnus) blitter according to the
  84.  official Amiga system specifications, in an OwnBlitter()/DisownBlitter()
  85.  context. In the case of RTG environments which use Fast RAM for bitmaps, a
  86.  copy of the bitmap was created in Chip RAM, if this was required to give
  87.  the Amiga blitter access to the data.
  88.  
  89.  In more recent times, the use of the blitter, once an advantage the use of
  90.  which was encouraged by Commodore, has more and more become a penalty: not
  91.  only are recent CPUs faster than the Amiga blitter, but certain systems
  92.  (e.g. DraCo) do not provide low-level blitter functionality. Also, RAM
  93.  requirements now tend to abundantly exceed the limited sizes of the Chip
  94.  RAM which can be accessed by the original Amiga blitter.
  95.  
  96.  Personal Paint 7 includes a set of "virtual blitter" functions, which use
  97.  the CPU or other processors to achieve effects previously delegated
  98.  exclusively to the Amiga blitter (and which therefore required Chip RAM).
  99.  The program can selectively or automatically use a library employing the
  100.  Amiga blitter, or rather use another library which uses the CPU. This is of
  101.  advantage when there is no blitter, when the CPU is faster than the
  102.  blitter, and/or when Chip RAM is particularly slow or precious (as long as
  103.  graphics.library functions do not require Chip RAM, which is also checked
  104.  for). Hybrid libraries are also possible, as are 68K-replacement libraries
  105.  (e.g. PowerPC), or 68K libraries especially compiled for certain processors
  106.  (e.g. 68040).
  107.  
  108.  The user can normally switch between the use of one library and the other
  109.  by toggling the "Blitter" setting in the program user interface. In the
  110.  event that the "Blitter" setting is active, but there is no blitter, the
  111.  program tries to detect this condition and use the other library. Detecting
  112.  this condition (no blitter on the host system) is not standard (not having
  113.  a blitter is "not standard"...), especially when Amiga blitter
  114.  functionality is partially emulated, and we therefore would ask developers
  115.  of new "blitterless" systems to let us know how such a condition can be
  116.  detected, so that we can update the libraries. Also, we would very much
  117.  like to know about any new graphic systems in which the graphics.library
  118.  functions can work on Fast RAM (e.g. how that can be detected, what
  119.  functionality is provided).
  120.